auto merge of #861 : alexcrichton/cargo/issue-800, r=brson
authorbors <bors@rust-lang.org>
Fri, 14 Nov 2014 22:44:28 +0000 (22:44 +0000)
committerbors <bors@rust-lang.org>
Fri, 14 Nov 2014 22:44:28 +0000 (22:44 +0000)
commitb6c19b8b2823b789511297f83c2ff176212ce7fa
tree854276c7b60989af887b3a8785fefb7a2588f261
parentbfcc65c7fc85cce3474e6691b012d4ce861ba4a5
parent7a942be8c5c39487083af13be47e2144d66b44e0
auto merge of #861 : alexcrichton/cargo/issue-800, r=brson

This commit is an architectural change inside of Cargo itself in the way that it
handles the output format of builds. Previously when a build start, all existing
directories and files would be renamed to `old-foo` folders. The build would
then `rename` all files back into the right location as they were seen as fresh
and needed for the build.

The benefit of a system such as this is a rock-solid guarantee that the build
tree contains exactly what it would if we were to start the build from a totally
clean directory each time. There are some downsides, however:

* In #800, it was discovered that this method has an unfortunate interaction
  with Docker. Docker apparently will mount many filesystems which `rename` will
  not work across.

* I have seen countless flaky failures on windows due to an attempt to remove a
  file that was still in use somehow. I've never been able to truly track down
  why these failures are happening, however.

The new system for managing output files is to build up a list of all known
files at the start of a build, whitelist any necessary files when the build is
being prepared, and then wipe out all unknown files right before the build
begins. This is not quite as close to the guarantee as the benefits reaped
before because on the second build all build files will still be in their final
output locations, they may just get updated as part of the build as well. This
seems like an acceptable compromise, however.

Closes #800